Occasionally, novel products are introduced into the marketplace with their demand far exceeding their supply. Take, for example, Apple's iPad and iPad2. These items were launched to crowds of consumers waiting outside stores for hours to purchase a limited supply of products. While the seller (i.e. manufacturer, retailer, etc.) may be overjoyed at the demand, such a situation does not create a good customer experience. Purchasers may stand in line for hours only to be told when they reach the counter that there are no products left for them. Anger flares when some consumers purchase multiple quantities for resale on internet auction sites or in foreign countries where the items are not available via legitimate markets, and leave those waiting in line behind them with nothing.
An ecommerce solution solves some of these problems. Rather than wait in line for hours with uncertain results, consumers may access an online store to purchase the item. The purchaser could even preorder the item in order to receive it when it hits the market. However, business, technical and functional challenges still exist, especially if the ecommerce system infrastructure and surrounding technology are not prepared to handle unusually high demand.
Periods during which online applications receive an exceptionally high volume of transactions, such as holidays or during preorder or release of long-awaited products, present a number of technical and user-experience related issues. As those of ordinary skill in the computer arts are aware, there are some general issues around traffic that all online applications face with being on the internet. Designing an online system involves designing for performance. Performance is impacted by the interest and interaction with the application online. Whereas a desktop application may involve just one user operating the software at a particular time, users of an online application may number several to millions of people at the same time.
Online applications are architected and sized for performance under normal or typical conditions and do not work well when traffic spikes. For example, the owner of a population of servers with information that is provided frequently to the internet will want that information to be cached in memory so that repeated access to that information is quick and inexpensive. Under load, that cache can benefit performance. However, if the system does not have enough traffic hitting the cache servers, enough to keep the cache “warm” (where cached items are frequently requested), then users who trickle into the site will have poor performance. So, when developers design and build an internet application, they build in an amount of cache and population of web servers that size to the amount of traffic that will normally be expected. That system is then tuned to expect that in most circumstances the users are getting the benefit of the cache. If a spike event occurs, a period of high volume, high demand on the system, the system breaks down.
It is unrealistic, in time and cost, to grow the size of the infrastructure to meet spike, or high demand, loads as they occur, and system issues develop if the system is scaled to operate at the increased level of traffic. Referring again to the caching example above, once the traffic subsides the typical amount of traffic received will not induce the algorithms behind the scenes to keep the cache populated effectively. The infrastructure required for a spike event is poisonous to normal traffic and the infrastructure needed for normal traffic is insufficient to meet the needs of the spike.
For online commerce, poor performance of a web store is associated with a very low close rate. Although users are not physically standing in line, they are in a very real, electronic queue. An electronic queue may be even more congested than a physical queue because of the centralized nature of ecommerce purchasing and the system issues discussed above, resulting in connectivity or communication problems if the system is not sufficiently robust. A high volume of requests headed for the same web server must pass through the network, the network interface to the server and the server's operating system prior to getting to the web server itself. An overload of requests may cause issues at any one of these points, frustrating the user's efforts to get to the destination web server. An overload of requests hitting the web server will result in an unwanted error page presented to a user, who may give up trying to access the site in frustration, or just forget to come back later. If limits are placed on the quantity that may be purchased, the user must not lose his place in queue or he risks losing the item, and the merchant risks losing the sale. Finally, once stock is depleted, the seller may lose any information on the user, who may not be willing to come back when more stock is available.
Due to the constraints and issues around internet communications, and real-time sizing of infrastructure to meet demand (e.g. lack of time and capital), an e-commerce merchant must be prepared with a system solution in order to handle high volume requests. The present disclosure solves these and other problems and offers other advantages over the prior art by providing an additional, integrated architecture that can handle spikes in requests and allow the user to interact in real time without expanding the basic internet commerce infrastructure.